Synchronization of disparate databases

ABSTRACT

A data processing method for synchronizing the data records of a plurality of disparate databases, in which a status file is provided containing data records representative of the contents of data records existing in the disparate databases at a prior synchronization. Data records from at least a first and a second of the plurality of databases are compared to corresponding data records of the status file to determine whether data records of the plurality of databases have changed or been deleted since the prior synchronization, or whether there are new data records since the earlier synchronization. Based on the outcome of the comparing step, decisions are made as to how to update the data records of the first and second databases. Finally, the status file is updated so that its data records are representative of the contents of the data records of the first and second databases after they have been updated.

BACKGROUND OF THE INVENTION

[0001] This invention relates to programs that synchronize databases.

[0002] There are many situations in which it is important for a user tobe able to synchronize databases among computers. For instance, manyusers have handheld computers, which typically weigh less than a pound,fit in a pocket, and provide some combination of personal informationmanagement functions, database functions, word processing functions, andspreadsheet functions. Many users of handheld computers also own desktopcomputers used for applications that manage databases similar to thedatabases carried in handheld computers. Typically the user adds data tothe two computers independently, e.g., one enters data into the handheldcomputer when out at a customer site but enters data into the desktopcomputer when in the office. In such cases, the user normally would atsome point want to synchronize the databases on the handheld and desktopdatabases, i.e., automatically review changes made to the databases onthe two computers, and revise the data in both databases so that bothhave the same and most current data.

[0003] Databases are collections of data organized as data records, eachcomposed of a number of data fields. For example, in an addressdatabase, a very simple data record might be “John, Smith, Smith Co.”,where “John” is the information content of a FIRSTNAME field, “Smith” isthe information content of a LASTNAME field, and “Smith Co.” is theinformation content of a COMPANYNAME field.

[0004] Databases are managed by two broad classes of programs, databasemanagers and special-purpose application programs (both referred toherein as database programs). A database manager is a program formanaging general databases, that is, databases in which the structure ofthe data records can be specified at creation time by the user. Otherdatabases are managed by special-purpose application programs, e.g., atelephone directory program of a handheld computer. Unlike the recordstructures of general databases, the record structures of thesespecial-purpose databases typically are not specified by the user.

[0005] There are generally two ways in which software can specify arecord in these databases. One or more of the fields of a record can bedesignated as a key, with particular records being specified by thecontents of the key (e.g., the above-mentioned address database mightuse the LASTNAME field as a key, so that records could be specified bythe contents of that field). Records can also be specified using uniqueidentification numbers (“unique IDs”), assigned by the database programat the time the record is created.

[0006] There are known techniques for synchronizing databases, but theygenerally depend on the databases having been specially designed tofacilitate synchronization. For example, Microsoft Schedule+ permitsmultiple Schedule+ databases to be synchronized, but this is onlypossible because Schedule+ was specially designed with synchronizationin mind. Similarly, directory databases built in conformance with theCCITT X.500 international standard can be synchronized by virtue ofconforming to this standard. One way in which synchronization isachieved in such products is by the use of unique IDs assigned when arecord is created. During synchronization, the software is able to usethe unique IDs to compare the contents of corresponding data records inthe two databases (e.g., corresponding data records for the same dinnerappointment can be compared even if the date, time, or description forthe appointment has been changed in one or both databases).

[0007] Another feature available for synchronizing databases speciallydesigned for synchronization are not-yet-synchronized flags, which areset whenever a record is changed (e.g., when a dinner appointment ismoved to a new date and time). If the software finds a discrepancyduring synchronization, the program then checks each record'snot-yet-synchronized flag and, if one flag is set and the other is not,the data in the record with the set flag prevails because it is assumedto be newer. If both flags are set, the data transfer program resorts tousing a trump rule (e.g., handheld always prevails over desktop) orinteracting with the user because the program does not have enoughinformation to choose one over the other. After synchronization all ofthe flags are reset.

[0008] Also available when databases have been specially designed forsynchronization is a time-and-date-of-last-modification stamp for everyrecord stored in the databases. Assuming sufficiently accuratesynchronization of the time-and-date clocks of the computers running thedatabases, the synchronization program can always determine, even ifboth of the corresponding items have been changed since lastsynchronization, which change is the most recent, and assume that themore recent record prevails. But such time and date stamping of recordswill typically be impracticable owing to the scarcity of memory and filespace, especially on a handheld computer.

[0009] With databases not specially designed for synchronization, therehas not heretofore been any practical technique for synchronization. Ithas been necessary to use either (1) brute force replacement of all ofthe records of one database with all of the records of the other (e.g.,using software such as LapLink) or (2) a reconciliation techniquedeveloped by IntelliLink Corp., of Nashua, N.H. (described in U.S.patent application Ser. No. 07/867,167, filed on Apr. 10, 1992;incorporated by reference).

[0010] IntelliLink's reconciliation technique uses key fields (e.g., thedate and time of appointments in a calendar database) to establish acorrespondence between records of the two databases, and then examinesthe records for differences (e.g., a different appointment descriptionfor the same date and time). The differences are reconciled either byinvoking one or more trump rules (e.g., handheld always prevails overdesktop) or by interacting with the user (e.g., by displaying therelevant mismatching information and asking the user to choose).

[0011] An advantage of the reconciliation technique is its ability tohandle disparate databases (e.g., databases with different datastructures, designed for use with different application software and ondifferent computer platforms). To do its job, the IntelliLinkreconciliation technique does not require the presence of specialsynchronization-enabling features such as unique IDs,not-yet-synchronized flags, or time-and-date-of-last-modificationstamps. It can work with databases of radically different design, byfirst translating the differently structured databases into a commonintermediate format, and then using key fields to establishcorrespondence between records. Yet despite those advantages, and thefact that the reconciliation technique was a huge improvement over thebrute force replacement technique that existed before it, reconciliationstill falls short of real synchronization.

[0012] One difficulty with the existing reconciliation technique is thatunless a trump rule such as “handheld always prevails over desktop” isemployed, the user is interrogated every time there is a data mismatch,and that interrogation necessarily takes up a lot of time.

[0013] In addition, the reconciliation technique does not handle datadeletions well, because it inherently assumes that if an item on onecomputer is empty and its corresponding item on the other computer isnot, the empty item should be updated with the non-empty item. Thismeans, e.g., that when a user deletes an appointment from a calendardatabase on one computer, that appointment could be restored duringreconciliation, defeating the user's attempt to delete it.

SUMMARY OF THE INVENTION

[0014] The invention makes possible synchronization of disparatedatabases, overcoming the shortcomings of the prior reconciliationtechnique. It does so by providing a status file which allows thesynchronization program to determine if data records in one or moredatabases have been changed or deleted since the last synchronization,or whether new data records have been added.

[0015] Preferably, the status file contains the data present in the twodatabases after the most recent synchronization. Corresponding sets ofrecords are chosen from each of the two databases and from the statusfile, and a comparison is made of the information content of therecords. Based on that comparison, updating decisions are made for eachset of records, for example, decisions are made whether to select theinformation content of one database record over the information contentof the other, and finally the selected information is written to thestatus file as well as the databases.

[0016] The invention makes it possible to synchronize databases ofradically different design, operating on different computer platforms.E.g., a calendar database proprietary to a particular handheld computeror personal digital assistant (PDA) can now be synchronized with acalendar database running on a user's desktop (e.g., Lotus organizer, orMicrosoft Schedule+).

[0017] With the invention, it becomes quite practical for a person touse both a PDA and a desktop calendar database in a group schedulingenvironment, i.e., one in which calendar databases are interconnectedbetween users so that appointments may be added and deletedautomatically. Now if an appointment is added or deleted on onedatabase, for example, the user's desktop, the synchronization processof the invention can recognize that such has occurred and automaticallyupdate the other during a synchronization.

[0018] Synchronization of disparate databases can be performed with muchless user interaction than was necessary with the prior reconciliationtechnique. E.g., by applying a rule that newer database changes prevailover older changes, in connection with a preferred decision matrix, theuser can allow synchronization to occur with minimal or no interaction.

[0019] The invention permits databases that were specially designed forsynchronization to be synchronized with databases that were not sodesigned. Embodiments of the invention can work with databases thatprovide time-and-date-of-last-modification stamps, not-yet-synchronizedflags, or unique IDs, but also with databases that provide no suchstamps, flags, or IDs.

[0020] The invention also provides a backup function for information ina database because the status file can be used to reconstruct acomplete, earlier version of the database.

[0021] The invention may be used to synchronize two or more databases onthe same computer or on different computers.

[0022] Other features and advantages of the invention will be apparentfrom the following description of preferred embodiments, and from theclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0023]FIG. 1 illustrates both a handheld and a desktop computer, andshows, diagrammatically, a database and data records for each.

[0024]FIG. 2 shows a handheld database, status file, desktop database,and temporary workspace of a preferred embodiment of the invention.

[0025]FIG. 3 is a flowchart of the preferred embodiment.

[0026] FIGS. 4-6 are three sections of a flowchart showing the preferredembodiment in more detail.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] Shown in FIG. 1 are two computers on which disparate databasesreside, a database 7 in a handheld computer 1 and a database 11 in adesktop computer 3. Synchronization depends on knowledge of: (1) howrecords 5 in one database 7 correspond to records 9 in the other 11 and(2) the history of updates in each database. For correspondence, thesynchronization program relies on the basic translation and mappingcapabilities of the prior IntelliLink reconciliation technique (e.g., asdescribed in U.S. patent application Ser. No. 07/867,167, filed on Apr.10, 1992, referred to earlier).

[0028] The synchronization program is typically run repeatedly overtime. E.g., the user may choose to run synchronization daily, weekly, oron an irregular “as needed” basis.

[0029] When conflicts are detected during synchronization (i.e.,differences in the content of key fields), they may be resolvedautomatically or interactively, depending on user preference. The usermay select among different automatic rules, including:

[0030] 1. Always propagate deletions even if that means deleting arecently changed item.

[0031] 2. Let handheld changes override desktop changes.

[0032] 3. Let desktop changes override handheld changes.

[0033] 4. Keep both versions and no longer attempt to reconcile them.

[0034] 5. Leave the conflict unresolved.

[0035] If a conflict is to be resolved interactively, the user ispresented with a dialog box that allows the user to select one of theserules.

[0036] Since it is possible that a user may enter the same newinformation into both the handheld and the desktop computer, thesynchronization program checks for this possibility in order to avoidduplication of data. The program compares all new desktop records withall new handheld records, and, when matches are found, the matches areassumed to correspond to one another.

[0037]FIG. 2 shows the data structure of a preferred embodiment. Thereare three databases: handheld database N, desktop database V, and statusfile P. In this embodiment, the handheld database has unique IDs thatidentify its records, but the desktop database has no such IDs, and itsrecords are identified through the use of key fields. The handheldrecords are mapped to desktop records using a key field or set of keyfields. For example, in a telephone database, the mapping could be doneusing the LASTNAME field as the key field. This makes it possible toachieve a correspondence between the handheld IDs and the desktop keyfields. For example, a handheld record with an ID of “A987” ends upassociated with a desktop record identified by the key fieldLASTNAME=“Smith”.

[0038] The following descriptions assume that all of the correspondingrecords of the handheld database and the desktop database have alreadybeen mapped using such existing methods. The records in the status fileare identified using IDs originating in the handheld database. FIGS. 2-6use the following abbreviations: P for status file, N for handheldcomputer database, V for desktop computer database, and S forsynchronization workspace.

[0039] The synchronization workspace S is a temporary memory workspaceused by the synchronization program. The workspace S maintains severalpieces of information for each record in the database, including ahandheld-ID, a CRC value, and status indicators providinghandheld-status and desktop-status. The handheld-ID is a unique IDidentifying each record in the handheld database. The CRC valueidentifies a desktop record, and is obtained using a well-knownalgorithm that maps a unique variable-length string of data to a nearlyunique integer of shorter, fixed length. E.g., if the key fields used toidentify a desktop record are Firstname, Lastname, and Company Name,then the CRC value would be a short, fixed length integer derived from astring such as “John, Smith, Smith Co.” Methods of comparing strings ofdata are well-known in the art; this embodiment uses a method in whichfirst the CRC values of strings are computed and compared; if the CRCvalues match, the full strings are then compared directly.

[0040] Handheld-status and desktop-status generally indicate the statusof the handheld and desktop data records with respect to correspondingrecords in the status file. For example, a previously synchronized itemthat has since been changed in the handheld computer but is unchanged inthe desktop would have handheld-status set to CHANGED and desktop-statusset to UNCHANGED. Since handheld records are correlated first, beforedesktop records, the meaning of handheld-status is slightly differentfrom the meaning of desktop-status. Handheld-status describes handheldrecords relative to status file records only. Desktop-status, on theother hand, describes desktop records relative to status file recordsand any new handheld records.

[0041] The status file P, which is saved after a synchronization andused as input to the next synchronization, is a file containing onerecord per pair of synchronized handheld and desktop records. Eachstatus file record (each line in file P in FIG. 2) is a simpleunconflicted record, i.e., is identified by only one set of key fieldsor IDs. Due to prior mapping of handheld records to desktop records, theuse of only one set presents no problem with respect to the other set.In this embodiment, status file records are identified by handheld-IDs,but in the case where there are no IDs in either database, the statusfile records could be identified by a key field from one database.

[0042]FIG. 3 shows the synchronization process. The previous status fileis read (step 200). This gives a list of records. The first time thatsynchronization is run, no previous status file exists, in which casestep 200 produces an empty list of records.

[0043] Synchronization begins with the program retrieving records fromthe handheld database and comparing them to the records in the statusfile (step 205). For every handheld record, the synchronization programtakes note of the record's status, i.e., whether a corresponding statusfile record exists, and if so, whether the handheld record has beenchanged. If there are new handheld records, i.e., records in thehandheld database that are not in the status file (e.g., new telephonenumber entries in a telephone database, or new appointments in acalendar database), the synchronization program retains these newhandheld records for use in subsequent steps.

[0044] Next, the synchronization program (step 210) retrieves recordsfrom the desktop database and compares them to the records in the statusfile and the new handheld records. For every desktop record, thesynchronization program takes note of the record's status, i.e., whethera corresponding status file record exists, and if so, whether thatrecord has changed in the desktop database. If there are new desktoprecords, i.e., records in the desktop database that are neither in thestatus file nor among the new handheld records, the synchronizationprogram takes note of these new desktop records for subsequent steps.

[0045] After this comparing step, the synchronization program (step 215)uses a decision matrix to generate a To-Do list of actions to be takenwith respect to the records in the handheld database and the desktopdatabase. The decision matrix takes as inputs the status with respect tothe status file, i.e., CHANGED, UNCHANGED, NEW, or ABSENT, of eachrecord in each record set and outputs a To-Do list action item for eachrecord set. For example, if the status of a handheld record is UNCHANGEDand the status of its corresponding desktop record is CHANGED, then thedecision matrix output action item is to update the handheld record andthe status file record to match the desktop record.

[0046] Finally, the synchronization program (step 220) goes through theTo-Do list and performs updates to the desktop database, handhelddatabase, and status file. If any of the updates to the desktop andhandheld databases are unsuccessful, the synchronization programrefrains from making these updates to the status file, so that thesynchronization program will retry the update at the nextsynchronization.

[0047] FIGS. 4-6 show the synchronization process in more detail. Theinformation in status file P is copied into synchronization workspace S(step 300). Arrays of handheld-IDs, CRCs, and status indicators arecreated and populated in workspace S (step 305). All status indicatorsare initialized with handheld-status set to ABSENT and desktop-statusset to ABSENT. Subsequent processing steps will change these statusindicators to other values if the corresponding records still exist inhandheld database N or desktop database V or both.

[0048] Handheld records are loaded, one by one, into workspace S. Inthis loading process, incoming handheld records are correlated withpre-existing status file records using the handheld-ID as thecorrelation key (step 310). When a match of IDs is found, all mappedfields of the handheld record and status file record are compared (step315). If all fields match exactly, handheld-status is set to UNCHANGED(step 320), but otherwise handheld-status is set to CHANGED (step 330).If handheld-status is set to CHANGED, all data from the handheld recordis stored in workspace S alongside the data from the correspondingstatus file record. No further “conflict resolution” action is taken atthis point in the procedure.

[0049] If there is no status file record with the same handheld-ID asthe incoming handheld record, the incoming handheld record is stored inworkspace S (step 325). For this incoming handheld record, itshandheld-ID is retained, the CRC of its key fields is computed andstored for later use in a possible match to a desktop record, and itsstatus indicators are set as follows: handheld-status is set to NEW anddesktop-status is set to ABSENT.

[0050] Steps 310-335 are repeated for all handheld records (step 335).

[0051] Once the last handheld record is processed, correlation ofhandheld records with status file records is complete. From this pointon in this procedure the term handheld record refers only to any recordin workspace S for which handheld-status is set to NEW.

[0052] Desktop records are loaded, one by one, into workspace S (FIG.5). For each desktop record, first an unused exact match is sought. Anunused exact match is a status file record or new handheld recordwherein all fields match those of the desktop record (step 340) anddesktop-status is set either to ABSENT or CHANGED (step 345). If such amatch record is found with desktop-status set to ABSENT (step 350),desktop-status is simply updated to UNCHANGED (step 360). However, ifsuch a match record is found with desktop-status set to CHANGED, thismeans that there is more than one desktop record that maps to the matchrecord. It also means that when a previous desktop record was loaded, itwas identified, using key field matching as described below, as apartial match for this handheld or status file record. Now the partialmatch is replaced with the present desktop record, desktop-status is setto UNCHANGED, and then the partial match is run through the key fieldsearch again (step 385).

[0053] If no unused exact match is found, then a key field match issought (step 355). The key field match must also be unused, i.e., thestatus file record or handheld record found must also have adesktop-status that is set to ABSENT (step 365). If such a match isfound, desktop-status is set to CHANGED and all of the data in thedesktop record is stored alongside the data of the match (375). Nofurther “conflict resolution” action is taken at this point in timebecause this desktop record could eventually be replaced if an exactmatch is later found for this handheld or status file record, asdescribed above in step 385. If no unused key field match is found, anew record is created in workspace S with handheld-status set to ABSENTand desktop-status set to NEW (385).

[0054] Steps 340-385 are repeated for all desktop records (step 370).

[0055] Once all desktop records are exhausted, workspace S is scannedfrom top-to-bottom and decisions are made, using the decision matrix ofTable 1, about how to resolve any conflicts, either interactively ornon-interactively (FIG. 6, step 390). The decisions are not implementedimmediately but rather are held as actions items in a To-Do list. TABLE1 Decision Matrix Handheld- Desktop- # Status Status To Do 1 UNCHANGEDUNCHANGED Nothing. 2 UNCHANGED CHANGED Update handheld database N andworkspace S to match desktop database V. 3 UNCHANGED ABSENT Deleterecord from handheld database N and workspace S. 4 CHANGED UNCHANGEDUpdate desktop database V and workspace S to match handheld database N.5 CHANGED CHANGED If changes are independent, update handheld databaseN, workspace S, and desktop database V; otherwise use a conflictresolution (CR) dialog with the user or apply an automatic rule. 6CHANGED ABSENT Resolve CHANGE vs. DELETE conflict, either via CR dialogor by applying an automatic rule. 7 ABSENT UNCHANGED Delete record fromdesktop database V and workspace S. 8 ABSENT CHANGED Resolve CHANGE vs.DELETE conflict, either via CR dialog or by applying an automatic rule.9 ABSENT ABSENT Delete record from workspace S (it has already beendeleted from handheld database N and desktop database V). 10 ABSENT NEWAdd record to handheld database N and workspace S. 11 NEW ABSENT Addrecord to desktop database V and workspace S. 12 NEW UNCHANGED Addrecord to workspace S (synchronizing identical items here). 13 NEWCHANGED Resolve conflict, either via CR dialog or by applying anautomatic rule. (Note that this case is semantically different from case#5, so different automatic rules may apply, but the CR dialog may be thesame.)

[0056] All updates in the To-Do list for desktop database V areattempted (step 405). If a particular update, i.e., an ADD, CHANGE, orDELETE, is successful (step 395), the same update is also performed onthe corresponding record in workspace S (step 400).

[0057] Next, all updates in the To-Do list for handheld database N areattempted (step 420). If a particular update is successful (step 410),the same update is also performed on the corresponding record in S (step415).

[0058] Finally, all records with both handheld-status and desktop-statusset to ABSENT are deleted from workspace S (step 425). This reducesworkspace S down to a minimum size so that it contains only theinformation that must be stored as the new status file for the nextsynchronization.

Other Embodiments

[0059] Other embodiments of the invention are within the followingclaims. For example, whereas the embodiment described above synchronizeda database with records identified by IDs with another with recordsidentified by key fields, the invention also works with databases inwhich both databases have only records identified by key field, and withdatabases that provide time-and-date-of-last-modification stamps,not-yet-synchronized flags, or unified or non-unified IDs (as well aswith databases that provide no such stamps, flags, or IDs).

[0060] The invention is also not limited to use with a combination of ahandheld computer and a desktop computer (although it is particularlyadvantageous for such an environment). The invention may be used tosynchronize data of two or more desktop computers, two or more notebookcomputers, two or more handheld computers, or any combination ofmicrocomputers, minicomputers, mainframe computers, or other computers.The invention may also be used to synchronize two or more databases onthe same computer.

[0061] The invention may also be used to synchronize more than twodatabases. This can be accomplished, for example, by running thesynchronization program multiple times, each time synchronizing a newdatabase to an already-synchronized database. For example, in order tosynchronize databases A, B, C, and D, the synchronization program couldbe run first on A and B, then A and C, then A and D; or first on A andB, then B and C, then C and D, etc. Separate status files would bemaintained for each pair.

[0062] What is claimed is:

1. A data processing method for synchronizing the data records of aplurality of disparate databases, the method comprising the steps of:providing a status file containing data records representative of thecontents of data records existing in the disparate databases at a priorsynchronization; comparing data records from at least a first and asecond of the plurality of databases to corresponding data records ofthe status file to determine whether data records of the plurality ofdatabases have changed or been deleted since the prior synchronizationor whether there are new data records since the earlier synchronization;updating the first and second databases based on the outcome of thecomparing step; and updating the status file so that its data recordsare representative of the contents of the data records of the first andsecond databases after they have been updated.
 2. A data processingsystem for synchronizing the data records of a plurality of disparatedatabases, the system comprising: means for providing a status filecontaining data records representative of the contents of data recordsexisting in the disparate databases at a prior synchronization; meansfor comparing data records from at least a first and a second of theplurality of databases to corresponding data records of the status fileto determine whether data records of the plurality of databases havechanged or been deleted since the prior synchronization or whether thereare new records since the prior synchronization; means for updating thefirst and second databases based on the outcome of the comparing step;and means for updating the status file so that its data records arerepresentative of the contents of the data records of the first andsecond databases after they have been updated.
 3. The subject matter ofclaim 1 or 2 wherein the deciding step further comprises decidingwhether to delete a data record from the first database based on thecomparing step having determined that the corresponding record of thesecond database has been deleted since the earlier synchronization. 4.The subject matter of claim 3 wherein the comparing step comprises threesteps: a first comparing step comprising comparing data records from thefirst database to corresponding data records of the status file todetermine whether any of the data records of the plurality of databaseshave changed or been deleted since the prior synchronization or whetherthere are new data records since the earlier synchronization; storingnew status file data records representative of new data records found inthe first comparing step; and a second comparing step comprisingcomparing data records from the second database to corresponding datarecords of the status file and to the new status file data records. 5.The subject matter of claim 4 wherein status indicators for each of thefirst and second databases are produced on the basis of the outcome ofthe first and second comparing steps.
 6. The subject matter of claim 3wherein the status indicators comprise indicators indicative of thefollowing outcomes of the comparisons performed in the comparing step:(1) the database record is unchanged relative to the correspondingstatus file data record; (2) the database record is changed relative tothe corresponding status file data record; (3) the database record isabsent from the status file data records; (4) the database record isnew, meaning it is not among the status file data records.
 7. Thesubject matter of claim 5 wherein the status indicators compriseindicators indicative of the following outcomes of the comparisonsperformed in the first and second comparing steps: (1) the databaserecord is unchanged relative to the corresponding status file datarecord; (2) the database record is changed relative to the correspondingstatus file data record; (3) the database record is absent from thestatus file data records; (4) the database record is new, meaning it isnot among the status file data records.
 8. The subject matter of claim 3wherein the status file has a single set of data records, onecorresponding to each data record of the first and second databases atthe prior synchronization.
 9. The subject matter of claim 7 wherein thestatus file has a single set of data records, one corresponding to eachdata record of the first and second databases at the priorsynchronization.
 10. The subject matter of claim 3 wherein at least thedata records of the first database are each identified by uniqueidentification codes.
 11. The subject matter of claim 9 wherein the datarecords of the first and the second databases are without uniqueidentification codes.
 12. The subject matter of claim 10 wherein datarecords of the status file are identified by the unique identificationcode of the first database.
 13. The subject matter of claim 11 whereindata records of the status file are identified by at least one key fieldof the first database.
 14. The subject matter of claim 11 wherein thecorrespondence between data records of the first and second databases isachieved by comparing key fields of the databases.
 15. The subjectmatter of claim 11 wherein the correspondence between data records ofthe first and second databases is achieved by comparing key fields ofthe databases.
 16. The subject matter of claim 4 wherein the secondcomparing step further comprises storing further new status file datarecords representative of new data records found in the second comparingstep.
 17. The subject matter of claim 16 wherein a set of workspace datarecords are used during synchronization, the workspace data records eachhaving an identifier corresponding the identifier of the data records inthe status file, an status indicator for each of the first and seconddatabases.
 18. The subject matter of claim 17 wherein the new statusfile data records are stored first as workspace data records.
 19. Thesubject matter of claim 18 wherein following completion of the first andsecond comparing steps, the workspace data records are processed bycomparing each pair of stored status indicators to a decision matrix todetermine an action to be taken in updating the first and seconddatabases.
 20. The subject matter of claim 16 wherein the secondcomparing step further comprises examining for unused exact matches inthe data records of the second database.
 21. The subject matter of claim16 wherein the second comparing step further comprises examining for keyfield matches in the data records of the second database.